freedom 
of form 
foundation 


Newsletter for February 2024 


e Tail Project Update Part 2: Software 
e Integument Review Ch 1 and 4 are out! 
e Head anatomy video coming next month 


Tail Project Status 
Update Part 2: Software 


By Mecknavorz | February 5, 2024 


The goal of the tail project is to create a 
prosthetic tail that can be intuitively 
controlled through the wearer’s muscles. Our 
last article in December 2023 discussed the 
hardware side of things, focusing on the work 
Nalco and Bleddyn have done so far on 
designing and testing active electrodes for 
sensing muscle action. 


But how does all of this work from the 
software end of things? What kinds of data 
are produced by a system like the one we are 
designing and testing here at the FFF? How 
can we use these data to control a tail? 


Our 2023 started with my development of the 
seventh(ish) iteration of our embedded 
software. I abbreviate this version as “B7”, 
referring to the fact that Bleddyn, the tail 
team lead, wrote the first version of the 
software when the project started. Even 
though I have been working on the code since 
around the B3 version of the software, the 
naming convention wound up sticking. 


Anyway, this software has to run on 
something, which in this case is a 
microcontroller—essentially, a little chip that 
we can program to behave in a specific way 
when hooked up to external hardware. The 
microcontroller we use is an ESP32, which we 
have wired up to a MyoWare device that 
serves as a pre-amplifier for the 


electromyography (EMG) signals we're trying 
to measure. 


On Muscle Signals 

Now, it is important that we are able to 
extract useful data from the readings we make 
with the EMG pre-amplifier (the MyoWare). 
Our microcontroller converts this continuous 
analog signal to discrete digital data using a 
process called sampling. 


You can think of this process as working 
similarly to a film camera: if we want to 
faithfully reproduce the motion of a car 
driving at high speeds, we need to make sure 
that the frame rate at which we record this 
speedster is high enough to get multiple 
frames of the car moving. If our framerate is 
too low, we would be lucky to catch a glimpse 
of the car at all. If the frame rate is high 
enough, we can measure the time between 
frames to get an idea of when the car slows 
down or speeds up. 


Similarly, if we want to observe the actions of 
muscles as they initiate motion, we must take 
enough samples in a small enough time frame 
(Figure 1). Given the speed of signals we 
expect to observe in EMG, medical EMGs 
often use sample rates of 1024 Hz or 2048 Hz. 
This means that we want to be able to get a 
sample of our signal at least every 1/1024th of 
a second. 


To reach this transfer speed, I fiddled with 
minor details like the baud rate of the 
environment—essentially, how quickly the 
system is expected to send and receive 
information. I also simplified the code to make 
sure we were not performing extra tasks we 
did not need to be performing. After a few 
iterations, the B7 version of the code was able 
to achieve a sample rate of 1024 Hz! Fantastic! 


However, simply being able to sample the data 
still left us with a way to go. We want to be 
able to provide these data to the computer in 
real time, at first for plotting, and later, of 
course, for controlling a tail. 
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Fig 1: Illustration of the concept of a sample rate. If our sample rate is too low (blue plot), we do not get 
any meaningful information about the signal. If we increase our sample rate (green plot), then we start to 
see a meaningful representation of the signal, which allows us to work with it. 


Graphing and Error Correction 

My code was able to send samples of data at a 
sufficiently high speed, but in order make use 
of these data to learn about the signals in our 
muscles, we need to be able to process and 
visualize the data on a computer. This 
required new software on the computer, as 
well as further changes to the microcontroller 
software. 


On the computer side, we needed to set up 
software that would be able to read the data 
from the microcontroller at least as fast as it 
was produced, and then to perform basic 
operations in real time to graph the data. 
Being able to get this type of instant visual 
feedback from our hardware will make it 
much easier to identify the locations of 
muscles and the signals they generate. I opted 
to use Python to write this software because 
it is a language I am very familiar with, and 
because it generally makes implementation 
fairly easy compared to something like C++. 


Additionally, Python has a lot of very 
convenient libraries with features we would 
want to use, like graphing and 
multi-threading. 


Writing the graphing software is easier said 
than done, however, and a few issues reared 
their heads fairly early into this process. For 
one, we were trying to use Bluetooth to 
transmit data from the microcontroller to the 
computer. While this was convenient because 
of the Bluetooth transceiver built into the 
ESP32, our computer often received packets 
of data in a seemingly random order, turning 
the data into gibberish. 


Additionally, the Python serial library I have 
been using has its own shortcomings when it 
comes to reading and translating data. In this 
case, it automatically converted numerical 
data from the serial connection into strings 
that needed to be turned back into numbers. 
Converting a thousand samples of varying 


length per second, even on a fast computer, is 
not exactly efficient. I found that this lead to 
an overflow of the serial buffer, a built-in 
array of data from the serial connection that is 
queued up to be read by our computer. This 
caused the data fed to our live graph to turn 
into junk after about 20-30 seconds. 


Because of problems that arose while I was 
trying to graph the data on the computer, I 
made a few changes to the microcontroller 
code that I called the B7.1 version. The first 
change was to no longer use serial.print() 
(which outputs a “human”-readable string) 
and instead use serial.write(), which allows 
you to directly send bytes of data over the 
serial connection. This speeds things up by 
removing a lot of the overhead related to 
converting data from numbers to strings and 
vice versa, ensuring that the ESP32 is running 
as fast as it can. 


The second change that I introduced was the 
pawshake() function, something I 
implemented on both the ESP32 and on the 
computer. This function performs a simple 
back and forth with the 
computer’s code and our 
ESP32 to make sure the 
microcontroller does not start 
sending data too early and that 
the serial buffer on our 


OB Live MyoWare data 


computer system is clear 
before the ESP32 starts 
transmitting. The reason this 
helps is because it prevents us 
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While the changes made to the ESP32’s end of 
code allowed it to transmit as efficiently as 
possible, it was not without consequences for 
the computer. Instead of having a series of 
easy to comprehend data packets with easy to 
understand and identify breaks, the data 
being transmitted now formed a continuous 
flow of bytes which the computer had to chop 
up and interpret to recover the original 
sequence of samples. This in theory was fixed 
by the pawshake function: as long as we knew 
where the beginning was, we knew how to 
decode the whole batch of information. 


However, practice is often less forgiving than 
theory. Transmitting lots of data very rapidly 
was seemingly prone to mistakes: sometimes 
bytes got dropped, sometimes a packet got 
missed. This caused the “start” of our data to 
become somewhat obscured, especially the 
longer the program runs. As these mistakes 
compound, they make the data unreadable 
(Figure 2) until the program’s “start” point 
eventually strays so far from the original that 
it wraps around to the true beginning, 
sporadically giving us real data again. 


Fig 2: Example of graphing misaligned data. The y-axis is supposed to 
correspond to the voltage of the signals we are monitoring with the x- 
axis being time in seconds. However, multiple signal values are being 

mapped to the same time values. 
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To combat this gradual misalignment of data, 
fastRead() and fastDecode() were born as part 
of the computer software. Originally called 
fastGrab() and grabDecode(), both of these 
functions had to go through a few different 
revisions from mid-2023 to get them to their 
current state. 


As the name implies, fastRead() is designed to 
read from Python's serial buffer as fast as it 
can to prevent overflow and our data turning 
into junk. The other function, fastDecode(), 
primarily decodes the information that 
fastRead() stores for us, but additionally 
checks to make sure we are not misaligned 
with our data. 


Since we know the data we're looking for is 
always going to be in a certain range, we can 
look for decoded values outside that range 
and identify a misalignment. Specifically, the 
raw and envelope signals will always have a 
sampled value between 0 and 4095, while the 
time value should be a larger number than the 
last time value we found. When a 
misalignment is detected, the program quickly 
realigns itself by searching for expected 
values. This works similarly to the pawshake 
function, but modified for a moving start 
position instead of a fixed start position. 


Fig 3. Example of an early version of the code that was later implemented in fastDecode(). 


This shows the flow of bytes being correctly sliced up into the data we want. 
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Notes and Next Steps 

Getting the computer and microcontroller 
software working together was a far larger 
task than any of us imagined, but I made a lot 
of progress over the past year. Some features 
had to be put on the backburner for the time 
being to make sure we are able to get baseline 
functionality up and running in time to test 
our new hardware. Wireless connectivity with 
Bluetooth was a notable example—we hope it 
will be implemented eventually, but it is more 
important that we can graph and record the 
data first before doing so wirelessly. 


The next steps from here involve streamlining 
the graphing process. The Python graphing 
library, matplotlib, is going to be swapped out 
for faster libraries to further prevent 
slowdowns. Live graphing looms ever closer, 
and hopefully before long we will be on our 
way to mapping muscle signals! 


The Tail Project thanks FFF staff, volunteers, 
and the community for their support. Thanks 
as well to Bleddyn for providing feedback on 
this article. The equipment used in this work 
was paid for by FFF donors. 


Integument Review 
Update: Chapters 1 and 
4 are finished! 


By Tilt Wolf | February 27, 2024 


We are excited to announce that the 
Integument Review’s final report is beginning 
to be published! After over two years of 
intense research and a deep dive into the 
biology of human and nonhuman skin, we are 
releasing a compendium of underlying biology 
and realistic biological strategies for 
morphological freedom in the integument, 
with the intent to induce the growth of fur, 
feathers, and/or scales on human skin. 


We have drafted most of the planned 
chapters, spanning well over a hundred pages 
at present. We are now progressively 


conducting final reviews for each respective 
chapter, and will release them in sections. 


For this release, we are publishing Chapter 1 


(Properties of Fur) and Chapter 4 (Properties 
of Human Integument), which contain a 


detailed review of the underlying biology of 
fur as an integumentary structure in humans 
and other animals. To create biologically and 
functionally realistic results, we must describe 
the fine details of the systems we want to 
emulate: fur, feathers, and scales. 


We're also covering some of the major 
technical concerns that are intrinsically linked 
to what we are trying to do. For example, we 
are often rightly asked about how 
thermoregulation will work - we need to be 
sure that a newly created biological furry will 
not critically overheat from a new coat of fur. 
We performed simplified computer 
simulations to test this (Figure 4), and from 
this, we found that a full coat of fur is 
thermally safe at rest and under mild exercise 
(slow walking), but that lower ambient 
temperatures are required for more strenuous 
exercise like brisk walking or heavy work. 


Interestingly, we see a large benefit from a 
modest reduction in fur coverage. This could 
manifest, for example, as using sparser/ 
thinner fur to cover the abdomen or other 
areas of the body in a species-appropriate 
manner for optimal heat dissipation. We're 
also very interested in investigating other 
anatomical structures that mitigate thermal 
challenges, such as large, vascularized ears 
that very effectively dissipate heat. Fennec 
foxes do a great job of this in nature! 


In the near future, we will be releasing 
Chapter 2 (feathers) and Chapter 3 (scales) 
along the same lines. After that, we'll release 
the exciting latter parts where we develop 
theoretical frameworks and experimental next 
steps for reverse-engineering nonhuman 
integument to grow in humans. These will 
pave the way for a wide breadth of new 
research projects that turn theory into 
practice. 


Fig 4. Image from 
heat_transport_of 


spherical_furry.ipynb. 
The left side, at x=0.0, 


represents a naked 
human being. Furred 
anthropomorphs 
realistically reside in 
the region between 
0.6 to 0.95, as they 
will never have 100% 
fur coverage due to 
the nose, eyes, mouth, 
and paw pads being 
exposed skin. 


Maximum balanced ambient temperature (Celsius) 


0.0 


Thank you to all of our amazing volunteers 
who have made this possible, including our 
current team members (Lathreas, Rumi, and 
Mac) and all of our contributors along the 
way. You guys are awesome, and we wouldn't 
be able to do this without you. 


Also, a big thank you to all of our donors who 
support our projects - you all make this work 
possible, and I’m genuinely thrilled to see how 
our work will evolve into real world 
experiments in the coming months and years. 
Together, we will make furries real. 


Head Anatomy Video 
Series - Chapter 1 


coming next month 
By Zennith | February 29, 2024 


[just have one quick update here - the first 
video of the anthro head anatomy series is 
coming next month! I’m in the middle of doing 
final renders using our 3D models. 
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Feedback so far is very positive. The “A-roll” 
(me talking on camera) is complete, as are all 
of the scientific illustrations and all of the 
“B-roll” except for the ongoing renders. 


Iam SUPER excited about this and there’s a 
lot to look forward to. This video will answer a 
lot of questions about how real 
anthropomorphic head anatomy and 
physiology will function, while achieving 
results that look great and achieve patient 
goals. 


This'll be a whole thing next month, so... until 
then, I’m going to tease some screen caps on 
the next page. More soon! 


